feat(config): llm.runMode block — local | cloud | fusion with a fusion cloud-share dial - #161

…n cloud-share dial

Adds the config foundation for an operator run mode without changing any
behaviour: nothing calls `resolveRunMode` outside its tests yet.

`llm.runMode` sits beside `llm.fallback` rather than under `agent` (loop
budgets) or at the top level: `llm` has a single writer, and the mode and
`activeTextProvider` must move in one write + cache-reset cycle or they can
disagree.

`activeTextProvider` stays authoritative — `runMode.mode` is additive. The
effective mode is derived from which provider is active, and a stored
`fusion` is honoured only when the cloud leg is the active one. So an
operator who switches provider by hand in Manage → LLM simply drops out of
fusion on the next read: no reconciliation step, and no state that lies
about what is running. It also means fusion pins the cloud provider as the
fallback chain's primary, so `resolveFallbackChain` hoists it to the head
and appends local at the tail with no changes of its own.

`fusion.cloudShare` is documented as a dial, not a quota: it moves the
cutoff on a bounded per-step complexity score rather than promising that
N% of steps reach the cloud.

Degradation is explicit and reported rather than silent — cloud/fusion
without a cloud provider stays local, fusion without a local provider runs
cloud-only, and a pinned `toolTransport` warns without downgrading.

USER_CONFIG_VERSION 37 → 38. No migration code: `runMode` is an optional
sub-key of an already-optional block, so absence is exactly the v37
behaviour; the bump only records the schema change.

Verified: npm run lint and npm run build clean; npm test 4094 passed / 8
failed, the same 6 files / 8 tests that already fail on main @ 667dae1
(stale banner + tui-app fixtures, the `localModels.embeddings.url` fixture,
a dev-machine-specific fs-glob path, and send-message-concurrency).

…mmand

This branch takes USER_CONFIG_VERSION to 38. Hand testing showed what
that does to a machine that also has the installed v0.2.2 release: they
share one ~/.atomic-agent/config.json, so the moment the newer build
wrote v38, every single v0.2.2 command died with

  ConfigValidationError: invalid config: version: unsupported config
  version 38; expected one of 5, 6, ... 37

— models status, config get, the TUI, all of it, with no way out short
of hand-editing the file. Running a release and a build under test side
by side is normal, and the version bump made them mutually exclusive.

Every bump this schema has taken is additive: the parser reads field by
field and writeUserConfigFileSync preserves unknown top-level keys. So a
newer file already parses correctly — the allow-list only ever needed a
floor, not a ceiling. Older-than-supported is still refused, and a
non-integer version is now refused explicitly rather than falling
through the membership test.

ensureUserConfigFileSync gets the other half: it must not rewrite a
newer file back down to this build's shape. Reading it is safe;
overwriting would delete the newer build's keys, and with a shared file
the two builds would take turns destroying each other's config on every
launch.

Knowingly replaces the "rejects unsupported version" test, which pinned
the broken behaviour.